iT邦幫忙

2024 iThome 鐵人賽

DAY 10
1

目錄

摘要

在上一篇我們學到如何使用表達式跟function在workflow中設立條件、處理資料

在這篇我們會來了解一下自動、手動觸發workflow的事件

如何觸發workflow

就像是JS的事件一樣,我們必須自行把事件監聽綁在元素上,或者自行呼叫function,function才會被觸發

常見的workflow觸發事件大致上能分為自動、手動和排程幾種

透過on屬性可以定義觸發事件,且一個workflow可有多個觸發事件

首先不論是要自動、手動或排程,都用on:定義觸發事件

name: Foo
on:
  # 發PR到main、名稱含有release/的分支時觸發
  pull_request:
    branches:
      - main
      - release/**
    # ignore叫release/bar的分支
    branches-ignore:
      - release/bar

  # 手動觸發、無輸入欄位
  workflow_dispatch:

  # 排程,GMT+8每週一早上9點執行
  schedule:
    - cron: '0 1 * * 1'

觸發不在default branch上的workflow

不過如果你的workflow沒被推到default branch上過(通常是main或master),而你想要在發PR前試看看這個workflow,

那麼頗不幸的即便有定義workflow_dispatch,仍然無法在Github Actions的頁手動觸發他、使用Github Cli沒辦法,因為這兩個方法都不會列出不在default branch的workflow

# 列出default branch上可用的workflow,預設會把disable的藏起來
gh workflow list

# 列出default branch上所有workflow
gh workflow list -a
# workflow的name是name: 的值,不是檔名喔
# 以上面的例子來說就是Foo
gh workflow run <workflow的name> --ref <分支名>

如果硬要用指令觸發他,只會噴錯"could not find any workflows named <workflow的name>"

不過仍然可以使用偷吃步定義push: 解決

name: Foo
on:
  pull_request:
    branches:
      - main

  # 略
  push:
   branches:
    - 當下開發用的分支名

之後只要push到遠端就會被觸發了,也可以在Github Actions的頁、使用Github Cli的指令看到它

常用的觸發事件 & filter

使用filter用法跟正規表達式差不多,可以設置條件過濾分支、tag、commit之類的東西,除了常見的**和!,還有*、+、?之類的filter可以用,需要跳脫時字串時用\

在下面的例子中會示範使用當中幾種

另外需要注意的是,GitHub Actions 中,diff 只會處理 前300個變更檔案。如果你使用的filter没有在在前300個找到符合條件的更改,workflow就不會被觸發

自動觸發

  • pull_request

    name: Foo
    on:
      # 發PR到所有不叫release/bar的所有分支時觸發
      pull_request:
        branches:
          - !release/bar
    
  • push

    on:
    push:
      # 只在push的更動的檔案中有json檔時觸發
      paths:
        - '**.json'
      # 但是不檢查以下這些json
      paths-ignore:
        - .stylelintrc.json
        - .eslintrc.json
        - package.json
    
  • issue

    on:
      # 有新的issue時
      issues:
        types:
          - opened
    jobs:
      inform owner of repo:
        # 如果標題包含critical
        if: contains(github.event.issue.title, , 'critical')
    
  • issue_comment

    • 名稱有陷阱,你可能會以為只有在issue有留言時才會觸發,但其實PR有留言也會,而discussion的話則用discussion_comment
    on: issue_comment
    
    jobs:
      inform developer of PR:
        # 判斷是否為PR有新留言
        if: ${{ github.event.issue.pull_request }}
    
  • release

    https://ithelp.ithome.com.tw/upload/images/20240810/20135568ylumdCYRPm.png

    # 使用Github網頁發布新版本時(上圖黃圈處會多一個新版本)
    on:
      release:
        types: [published]
    

手動觸發

在前面的段落我們已經知道定義了workflow_dispatch可以手動觸發,但事實上不只手動觸發,甚至還可以設置input傳一些資料給workflow

但需要注意的是input上限是10個、65535字元,且最好設置options:避免使用者輸入一些奇怪的內容造成安全上的風險

on:
  workflow_dispatch:
    inputs:
      workspaceName:
        required: true
        default: 'foo'
        options:
          - foo
          - bar
      environment:
        description: 'Environment to run tests against'
        default: 'dev'
        options:
          - dev
          - alpha
          - beta
          - prod

在workflow內觸發另一個workflow

workflow_run

使用workflow_run,並定義types可以控制workflow間執行的順序,分為requested(開跑)、completed(完成)、in_progress(正在跑)

不過這個方法不能超過3層,如果硬要這麼做的話第4層開始就不會觸發 (A → B → C → D可以,超過D後就不行)

另外如果做的事情之間夠獨立的話,透過這種方式拆分workflow也能達到間接複用的效果,至於其他複用方式在之後的篇章會提到

name: (Runtime) Commit Artifacts for Meta WWW and fbsource V2

on:
  # 當名為(Runtime) Build and Test的workflow在main分支上跑完,且成功跑完後
  workflow_run:
    workflows: ["(Runtime) Build and Test"]
    types: [completed]
    branches:
      - main
    conclusion: success

repository_dispatch

repository_dispatch是一個很特別的事件,types完全是自訂的,不過types的名稱最多只能有100字元

它是透過Github API來觸發的,通常用於觸發點發生在Github之外時,至於如何建立repo dispatch event在之後的篇章會提到


上一篇
Day 09 - Github Actions的表達式 & function
下一篇
Day11 - workflow command
系列文
菜逼八用Github Actions30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言